…posed)

rvCSI was extracted to its own repo (PR ruvnet#542→ruvnet#544): 9 crates on crates.io @
0.3.1, `@ruv/rvcsi` on npm, vendored at `vendor/rvcsi`. RuView currently
*vendors but does not consume* it — zero `rvcsi-*` deps in `v2/`, zero
`use rvcsi_…` imports, zero `@ruv/rvcsi` JS imports. ADR-097 decides:

  D1 — Depend on the published crates from crates.io, not the submodule path.
  D2 — Pilot in `wifi-densepose-sensing-server` (smallest, best-bounded
       touchpoint: UDP receiver + handlers + WS fan-out).
  D3 — `wifi-densepose-signal` is *layered on top of* rvCSI, not replaced.
       The SOTA / RuvSense modules go beyond rvCSI's scope and stay in
       RuView; they consume `rvcsi_core::CsiFrame`. Overlapping basic DSP
       primitives delegate to `rvcsi-dsp` or become thin shims.
  D4 — `wifi-densepose-hardware` stops carrying ESP32 wire-format parsing;
       the parser moves to a new `rvcsi-adapter-esp32` crate (ADR-095 §1.2
       / D15 follow-up, owned in the rvCSI repo).
  D5 — `wifi-densepose-ruvector` (training pipeline) and `rvcsi-ruvector`
       (runtime RF memory) stay separate for now; a follow-up unifies them
       once the production RuVector binding lands.
  D6 — `rvcsi_core::CsiFrame` is the boundary type at the runtime edge;
       one explicit `From`/`Into` conversion point at that edge.
  D7 — Track via `rvcsi-* = "0.3"` SemVer ranges + bump the `vendor/rvcsi`
       submodule pin per RuView release for reproducible offline builds.
  D8 — Once every consumer depends on crates.io, decide (separately)
       whether to drop the submodule.

Adoption is phased (P1 pilot → P2 signal shim → P3 ESP32 adapter →
P4 clean-up → P5 submodule review); each phase is one PR with tests.

Indexed in docs/adr/README.md.

Co-Authored-By: claude-flow <ruv@ruv.net>